Intensional HTML

Intensional HTML is a high-level Web authoring language that makes practical (using standard client and server software) the speci cation of pages and sites that exist in many di erent versions or variants. Each page of IHTML de nes an intension | an indexed family of actual (extensional) HTML pages which varies over a multi-dimensional author-speci ed version space. The version space is partially ordered by a re nement/specialization ordering. For example, platform:mac can be re ned to platform:mac+language:french or to platform:mac%k68 and the last two both re ne to platform:mac%k68+language:french. Authors can create multiple labeled versions of the IHTML source for a given page. Requests from clients specify both a page and a version, and the server software selects the appropriate source page and uses it to generate the requested actual HTML page. Authors do not, however, have to provide separate source for each version. If the server-side software cannot nd a source page with the exact version requested, it uses the page whose label most closely approximates the requested version. In other words, it treats the re nement ordering as a (reverse) inheritance ordering. Thus di erent versions can share source, and authors can write generic, multi-version code. 1 The Versioning Phenomenon Many documents created for publication are produced in di erent variants or versions, corresponding, say, to di erent languages, di erent levels of expertise, di erent dates or di erent target audiences. In fact, most artifacts produced by humankind (documents or otherwise) appear in families of related versions, and the diversity in a family of documents (for example, user manuals) often simply re ects the corresponding diversity in a related family of more concrete entities. The advent of the World Wide Web has, if anything, increased the pressure on authors to create multi-version documents, for a number of reasons. Firstly, the Web is international, and a truly international site must be available in many di erent languages. The bandwidth available to users varies greatly, so that some appreciate high quality graphics while others prefer purely text pages. Di erent browsers have di erent capabilities, for example, in terms of tables and frames. Some sites o er more material to paying subscribers while others may want certain information hidden from outsiders. Some sites would naturally o er di erent information (e.g. weather reports) to people in di erent parts of the world. Finally, site designers might want to o er sites that are customizable to take personal preferences (fonts, background colors) into account. Furthermore, it seems at rst sight that it should be easier to support on the web than in print mediums. Web documents are fetched on demand, in response to requests from individual users who could, if necessary, provide at the same time relevant personal information (such as language or level of expertise). In principle, server software could take these parameters as input and generate a made-to-measure version of the requested document. In practice, however, there are very few sites which allow themselves to be recon gured according to user preferences. In particular, there are very few truly multilingual sites. Even large international corporations, which typically provide multilingual versions of their front pages, soon revert to the \default" (i.e. English) version for their inner pages. The problem lies with the very nature of HTML. HTML certainly allows pages to be generated on demand (through the CGI protocol) but provides no real support for authors who use it. CGI is an escape from HTML. Instead, authors usually stay with HTML and produce multi-version sites by cloning source les. Cloning works well in the short run, for a small number of versions, but breaks down when the version space is large and when the family of sites has to continue evolving. In this paper we propose an alternate solution: we extend HTML to a (slightly) higher level language which allows users to specify families of sites without the user cloning or, in the current implementation, escaping through the CGI gate. 1.1 The Problem with Cloning The easiest way to produce a variant of a web site is to make a copy of the HTML source and modify it. Unfortunately, the cloning (copying/modifying) approach to version creation can, in the long run, produce severe di culties maintaining the resulting families of versions. The problems arise when changes are required in parts of the original that were copied unchanged into the new versions. The same changes have to be made many times, in the sources for all the versions which used the original code. The inevitable result of the copy-and-modify approach is a large family of clones which, as a group, is almost impossible to change in any uniform way. The obvious solution is ensure that the di erent members of the family share the same code (and not copies thereof) so that necessary changes are made only once and need not be propagated. To use Ted Nelson's terminology, we must arrange that di erent versions transclude the source they have in common. This is easier said than done. In fact, exactly the same issues arise in the production of software (the documents being programs), and software version management is one of the most di cult problems in software engineering. Indeed, the success of the object oriented approach is due in part to class inheritance, which allows code to be shared (reused) on a large scale. HTML certainly allows two di erent pages to link to a third, but this is a very crude form of sharing. Links are essentially pointers, and the problem with sharing via pointers is that you also share everything the shared object itself has pointers to. Consider the problem of supporting English and French versions of a simple slide show. The slide show consists of a sequence of pages of text and/or graphics, each linked to the next page in the sequence. Obviously, we have to create separate English and French versions of pages with text on them. But we also have to make clones of any pages that have only images, even though the French and English versions will appear identical on the screen. The problem is that the English version of the page in question must be linked to the rest of the English version of the show, while the French version of the slide must be linked to the rest of the French version. Two separate source les are required. 2 The IHTML Solution In this paper we present IHTML (Intensional HTML), an HTML-based authoring language which incorporates an object-oriented (inheritance based) approach to hypertext versioning. IHTML allows authors to de ne, with a single source le, a whole indexed family of HTML variants based on the le in question. These variants are generated on demand, then discarded after use. In a sense, IHTML automates the cloning process, and eliminates the maintenance problem by ensuring that the clones are short lived. IHTML is intensional because IHTML source has both intensional and extensional meanings. The intension is the whole indexed family of HTML pages; the extensions are the di erent individual HTML pages. The main feature of IHTML is that authors can provide multiple sources for the same page, each source labeled with a di erent version. The IHTML server-side software accepts requests for particular versions of particular pages, and generates the actual HTML from the appropriate IHTML source les. For example, in the case of the slide show, the author could name the pages slide1, slide2, slide3, etc., and provide for each of these pages two source les, one English and one French. IHTML authors do not, however, have to provide separate source les for every possible version. The IHTML index space (\version space") is partially ordered by a re nement relation, and the source for a more re ned version is by default inherited from the less re ned (more generic) versions. When the server-side software receives a request for a particular version of a particular page (or part thereof), it looks for a source le labeled with the requested version. If there is no such source, it looks for a source le whose label most closely approximates the requested version (if there is no such source le, or no best source le, it reports an error). More re ned versions can therefore by default transclude source from more generic ones, and a relatively small number of source les can de ne a very large family of pages. For example, suppose that the fth slide is purely graphical. The author can provide a single source le, labeled as the standard (so-called \vanilla") version. When a request comes for, say, the French version of page slide5, the server software rst looks for a source le for that page labeled as the French version. When it nds none, it uses the more general standard version. Requests for the English version are similarly referred to the single standard source. 2.1 IHTML Links and Includes Normally, links in IHTML source look exactly like links in ordinary HTML. They are interpreted, however, as denoting a whole family of links, each connecting a given version of the page they appear in to the corresponding version of the page they link to. For example, suppose that the generic IHTML source for slide5 contains the link next page. This is interpreted as meaning that the English version of page5 is linked to the English version of page6, and that the French version of page5 is linked to the French version of page6. When the server software generates the French version of page5 from the generic source, it makes the generic link into a link to the French version of page6 (this might be the only change made). IHTML also has a \server-side include" feature which causes the contents of an included le to be incorporated (by copying) into the HTML page under construction. For example, each page of the slide show might have at the top and at the bottom, to include a standard header and footer in all slides. (The syntax was chosen to re ect the server-side include syntax of the Apache WWW server.) The IHTML includes are also generic; for example, the English version of page4will include the English version of the header. When processing an include, the server software looks for the version of the named source le whose version label most closely approximates the \current" version, i.e. the requested version of the le in which the include appears. Note that it looks for the requested version of the included le: the including page may exist in only a single, generic version, but a more speci c version of the included le will be used if one can be found. The include facility is very important for IHTML because it allows authors to break the source components into pieces smaller than a whole page. This allows the author to isolate the parts of a page that actually vary, and write more generic source for the parts (such as headers and footers) that do not. Conversely, the author may write generic source for a page as a whole, and include content which varies over whatever dimensions are appropriate. 2.2 The IHTML Version Space The families of pages speci ed by IHTML are indexed by (subspaces of) the algebraically de ned version space described in [1]. In the terminology of intensional logic [2], the elements of this space are possible worlds ; each individual possible world (version) determines a particular extension, i.e. an actual HTML page. The elements of the space described in [1] are expressions built up from identi ers using the operations + and %. The % operator is the subversion operator: V%s is (by de nition) a re nement of V . For example, Mac%k68 is a subversion of Mac. The + operator is the version join operator: the least upper bound in the re nement ordering. Intuitively, version V +W is the most general version which incorporates the modi cations/re nements of both versions V and W . For example, the Mac%k68+french version might be the version which is designed for 68K Macs and uses French as its interface language. Elements (versions) are partially ordered by a re nement operator: . This operator can be read as \is re ned by", or \is more general than". For example, V W says that W re nes V , or that V is more general (closer to \vanilla") than W . These ideas are formalized in the axioms presented in [1], for example: